Projektisuunnitelma

PDM-ryhmä
EAT-projekti

Tiivistelmä

Tässä dokumentissa on kuvattu PDM-ryhmän EAT -projektin projektisuunnitelma joka kuuluu Teknillisessä korkeakoulussa lukuvuonna 2000-2001 järjestettävään Tik-76.115 Tietojenkäsittelyopin ohjelmatyö -kurssiin.

Projektissa kehitetään ja toteutetaan TAI-tutkimuslaitokselle EDMS-dokumenttien hallintajärjestelmään ylläpitäjän työkalu. Työkalu kommunikoi TCP/IP yhteyden yli EDMS-palvelimen kanssa käyttäen valmiiksi määriteltyä protokollaa, jolla ylläpidolliset operaatiot tehdään. Projektin tarkoituksena on toteuttaa Java -kielellä ja Java Runtime Environment -ympäristössä toimiva graafinen ylläpitäjän työkalu, jota on helppo muuttaa tulevaisuudessa koko EDMS-järjestelmän kehittyessä.

Tämä dokumentti ohjaa myös projektiryhmän työtä kurssilla, joten dokumentti sisältää kurssin suorittamiseen tarvittavia tietoja ja prosesseja.

Sisällysluettelo

1. Johdanto

1.1 Projektin yleiskuva, tarkoitus ja kattavuus

1.2 Tuote ja ympäristö

1.3 Asiakkaan nykyinen ratkaisu

1.4 Projektin toteutusperusteet

1.5 Oikeudet työn tuloksiin

1.6 Yleikatsaus dokumenttiin

2. Termit ja määritelmät

3. Projektin organisaatio

3.1 Projektiryhmä

3.2 Vastuualueet

3.3 Sidosryhmät

4. Projektin tavoitteet ja päättäminen

4.1 Projektiryhmän tavoitteet

4.2 Asiakkaan tavoitteet

4.3 Projektin keskeyttämiskriteerit

4.4 Projektin päättämiskriteerit

5. Projektin resurssit

6. Projektissa käytettävät menetelmät ja työkalut

6.1 Katselmointi

6.1.1 Dokumenttien katselmointi

6.1.2 Ohjelmakoodin katselmointi

6.2 Työkalut

6.2.1 Kehitystyökalut ja apuohjelmat

6.2.2 Tiedonkulku

6.2.3 Raportointi

6.2.4 Dokumentitointi

6.2.5 Hakemistorakenne

6.2.6 Suunnittelumenetelmät

6.2.7 Ohjelmakoodin ulkomuoto ja kommentointi

6.2.8 Laadunvarmistus

6.2.9 Varmuuskopiointi

6.2.10 Palaverikäytännöt

7. Projektin ositus, vaiheistus ja resurssointi

7.1 Projektin suunnittelu

7.2 Toteutus 1

7.3 Toteutus 2

7.4 Toteutus 3

7.5 Toteutus 4

7.6 Luovutus

8. Mittarit, seuranta ja ohjaus

9. Riskienhallintasuunnitelma

10. Muuta

10.1 Projektiryhmän sisäinen koulutussuunnitelma

10.2 Asiakkaalle tarjottava koulutussuunnitelma

10.3 Asennussuunnitelma

Lähdeluettelo

1. Johdanto

1.1 Projektin yleiskuva, tarkoitus ja kattavuus

Järjestelmän ylläpitäjällä tarkoitetaan tässä henkilöä, joka toimii järjestelmää käyttävässä organisaatiossa ja jonka tehtävänä on sovittaa järjestelmä organisaation tarpeisiin. Ylläpitäjän täytyy esimerkiksi määritellä organisaatiossa käytettävät dokumenttityypit ja tyyppeihin liittyvät attribuutit. Ylläpito ei ole ohjelmointia vaan siinä käytetään järjestelmään kuuluvia ylläpitotoimintoja.

Dokumenttien hallintajärjestelmä on projektiryhmän työn kannalta valmis olemassa oleva kokonaisuus, johon projektimme lopputulos tulee ylimääräisenä apuohjelmana järjestelmän ylläpitäjälle. Tämän johdosta projektimme kattaa vain tarkasti rajatun osan koko dokumenttien hallintajärjestelmästä. EAT -ylläpitotyökalun tehtävänä on helpottaa ja visualisoida ylläpitäjän käytössä olevia operaatioita. Tälläinen visualisointi helpottaa ja nopeuttaa ylläpitotehtäviä, vähentää virheiden määrää (joka saattaa olla asiakkaan kannalta huomattava säästö, kun kyseessä on tuhannet tärkeät dokumentit) ja nostaa koko dokumenttien hallintajärjestelmän arvoa asiakkaiden silmissä.

EAT -työkalu tullaan rakentamaan Java:lla yhteensopivuuden maksimoimiseksi eri järjestelmissä, joista ylläpitotehtäviä voi joutua hoitamaan.

EAT -projektin ohella on menossa huomattava EDMS-järjestelmän kehitys, johon varaudutaan tekemällä EAT -työkalusta helposti muutettava tulevaisuuden muutoksia varten.

1.2 Tuote ja ympäristö

Dokumenttien hallintajärjestelmä on käytössä KONE Oyj:ssä, jossa sen alaisuudessa on lähes puoli miljoonaa dokumenttia. Tälläinen oikeassa käytössä olevan ympäristön olemassaolo tekee tuotteemme laatuvaatimuksista tiukan sekä motivoi ryhmän jäseniä, kun ohjelmisto ei jää vain teoreettiseksi tutkimukseksi. Koska EAT -työkalu tulee olemaan osa dokumenttien hallintajärjestelmää, tulee työkalu leviämään nykyisille ja tuleville asiakkaille koko järjestelmän mukana. Näin EAT -työkalua voidaan ajatella tuotteena sekä projektiryhmän että asiakkaan näkökulmasta.

EAT -työkalu on sekä tutkimusluonteinen että kaupallinen sovellus.

1.3 Asiakkaan nykyinen ratkaisu

Alla oleva kuva näyttää EDMS-järjestelmän perusrakenteen.

Kaikki dokumenttien tieto on talletettu tietokantaan, jota ohjaa palvelin, johon asiakasohjelmat ottavat yhteyden. Tämän mahdollistaa EDMS-protokolla, joka piilottaa alla olevan tietokannan asiakas-ohjelmilta. Asiakas ohjelmat siirtävät protokollan määritelmien mukaan tietoa tietokantaan tai hakevat sitä sieltä. Myös erilaisten tilannetietojen hakeminen on mahdollista. 

Asiakasohjelmia ovat mm. jo olemassa oleva tavallisen käyttäjän käyttöliittymä sekä komentorivipohjainen ylläpitäjän työkalu, jonka EAT -työkalu tulee korvaamaan.

Dokumenttien hallintajärjestelmän ylläpitäjä voi nykyisellään ohjata järjestelmää vain tekstimuodossa, kirjoittamalla käsin protokollan mukaisia käskyjä. Itse EAT -ohjelmiston toiminta tulee perustumaan valmiiseen protokollamäärittelyyn, jonka avulla ohjelma tulee kommunikoimaan TCP/IP-yhteyden (SSL valinnainen) yli protokollapalvelimen kanssa. Protokolla on ainoa, tarkasti määritelty, rajapinta ohjelmalle palvelimeen. Näin ylläpito-ohjelma on saatu rajattua muusta järjestelmästä erilleen.

1.4 Projektin toteutusperusteet

Asiakkaamme on lähinnä tutkimustoimintaa harrastava instituutio, joten heillä ei ole suurempia taloudellisia tavoitteita projektin suhteen. Järjestelmän kehittämiselle ei ole asetettu kriittisiä takarajoja. PDMG-ryhmä (joka on osa asiakkaan organisaatiota) tulee jatkamaan EAT -projektin lopputuotteen kehittämistä itsenäisesti kun projektiryhmä on sen luovuttanut asiakkaalle.

Asiakkaalle ei tule huomattavia laitteisto- tai ohjelmistokuluja (jos ollenkaan), koska suurin osa projektin työstä on suunniteltu tehtäväksi korkeakoulun tarjoamilla laitteilla ja ohjelmistoilla. Asiakas on kuitenkin tarjoutunut kustantamaan kohtuuhintaisia ohjelmistoja projektiryhmän käyttöön, jos se katsotaan tarpeelliseksi. Lisäksi asiakas on perustamassa ohjelmatyöhuonetta toimitiloihinsa. Ohjelmatyöhuone on tänä vuonna vain projektiryhmämme käytössä. Näillä näkymin sinne tulee ainakin yksi tietokone, jossa voimme käydä testaamassa EAT -työkaluamme kun sen kehitys on tarpeeksi pitkällä testavaksi erillään kehitysympäristöstä.

Asiakas on osoittanut ryhmän konsultiksi asiakkaan puolelta ohjaajan, jonka aikaa välttämättä menee projektiryhmämme ohjaukseen. Tämä ajan kulutus on luonnollisesti pois ohjaajan muusta työajasta ja aiheuttaa kuluja asiakkaalle. Asiakas on kuitenkin ottanut tämän huomioon tarjotessaan työtään projektiryhmälle. Ohjaajan panostus projektiryhmään oletetaan vähenevän mitä pidemmälle projekti etenee.

Integrointikuluja ei järjestelmän luovutuksen tms. vaiheen aikana tule, koska EAT -työkalu on aivan oma lohkonsa EDMS-järjestelmässä, eli EAT -työkalun valmistuminen ei aiheuta mitään muutoksia jo olemassa olevaan järjestelmään. Lisäksi EDMS-järjestelmä toimii hyvin, vaikkei EAT -työkalua olisikaan.

1.5 Oikeudet työn tuloksiin

Lisää sopimuksen yksityiskohtia voi tiedustella joko projektipäälliköltä tai asiakkaan edustajalta.

1.6 Yleiskatsaus dokumenttiin

Kappale kaksi kuvaa projektin kannalta oleellisia termejä ja määritelmiä. 

Kappale kolme kuvaa projektiryhmän organisaatiota, vastuualueita ja sidosryhmiä.

Kappale neljä sisältää tietoa projektin tavoitteista asiakkaan ja projektiryhmän näkökulmasta. Lisäksi on määritelty projektin keskeyttämis- ja lopettamiskriteerit.

Viides kappale sisältää arvioita ja faktoja projektin resursseista ja niiden aikataulutuksesta. 

Kappale kuusi kuvaa projektin työkaluja ja menetelmiä aina katselmoinnista hakemistorakenteisiin. 

Kappale seitsemän sisältää tarkemman kuvaksen projektin vaiheistuksesta ja resurssien jakamisesta projektihenkilöiden kesken. 

Kappaleessa kahdeksan on kuvailtu projektin mittareita.

Kappaleessa yhdeksän on tärkeää tietoa projektin riskienhallinnasta. 

Kappaleeseen kymmenen on kerätty muita projektiin liittyviä asioita.

2. Termit ja määritelmät

3. Projektin organisaatio

3.1 Projektiryhmä

Ryhmä: PDM
Kotisivu: http://www.hut.fi/~tratilai/pdm/
Email: tratilai@cc.hut.fi

Projektiryhmä koostuu aloitushetkellä seitsemästä henkilöstä. Projektin jäsenet muodostavat projektiryhmän, jonka tarkoitus on tuottaa asiakkaalle heidän haluamansa ohjelmisto. Asiakas on työn tilaaja, jonka osoittama ohjaaja ohjaa ja konsultoi projektiryhmää toteuttamaan ohjelmiston kuten asiakas sen haluaa.

Projektin jäsenillä ei ole muita sitoumuksia projektiin, kuin tässä projektisuunnitelmassa mainitut.

Käsittelemme projektissamme vastuualueita, joka poikkeaa kurssin ehdottamasta rooli-ajattelusta. Kyseessähän ei tulisi olla mikään rooli, jota näytellään, vaan vakavasti otettava vastuu jostain tietystä projektin osasta. Näin päädyimme "vastuualue"-käsitteeseen. Vastuualue ei kuitenkaan tarkoita, että kyseinen henkilö tekisi vastuualueensa määrittelemät asiat yksin. Koko projektiryhmä osallistuu lähes kaikkeen toimintaan projektissa (tai kuten tässä ja muissa dokumenteissa on määrätty), mutta vastuualueen henkilö on vastuussa lopputuloksesta ja projektin aikana vastuualueensa kontrolloimisesta. 

Yllä oleva kuva selventää ryhmän rakennetta. 

Ryhmä koostuu ohjelmoijista (kuvassa ympyröity), joita ovat kaikki muut paitsi Timo. Projektipäällikön ei ole hyvä osallistua koodaukseen vaan yrittää pitää näkemys koko projektin tilasta ikään kuin ulkopuolelta katsottuna, jota ei välttämättä pystyisi tekemään jos esimerkiksi ohjelmoisi jotain tiettyä moduulia projektissa.

Olemme jakaneet ryhmän pareihin, jotka tekevät mahdollisimman paljon samankaltaisia töitä projektin aikana tai ainakin tuntevat parinsa työn periaatteet. Tätä auttaa esimerkiksi se, että moduulitasolla koodi katselmoidaan ja testataan myös parin toimesta. Tällä parannetaan mahdollisuuksia selviytyä tilanteesta, jossa jokin ryhmän jäsen olisi estynyt suoriutumaan tehtävistään syystä tai toisesta ja projektiryhmä joutuisi jatkamaan vajaamiehisenä.

Yllä olevaan organisaatiomalliin ovat sitoutuneet kaikki ryhmän jäsenet. Parit on yritetty muodostaa kiinnostuksen, taitojen ja projektin työtehtävien kompromisseina. Taitotasolla parit on muodostettu siten, että kokenut Java-ohjelmoija on laitettu vähemmän kokeneen pariksi. Tällä yritetään maksimoida ryhmän sisäistä kompetenssia, kun vähemmän kokenut pääsee työskentelemään kokeneen parina ja luultavasti oppii paljon. Tätä kompetenssin kasvua voi toivottavasti jokainen hyödyntää jo projektin aikana omassa työssään.

Anssi on kokenut Java-ohjelmoija, jonka parina yleisessä koodauksessa työskentelee Miiku. Jonne on erittäin hyvä Java-käyttöliittymien kehittäjä, jonka pariksi tulee tietoliikenteestä paljon tietävä Jaakko. Tero hyvänä koodaajana, sekä tietotekniikan yleismiehenä ja Jukka peruskoodaajana muodostavat yhteen sopivan parin. Lisäksi Jukalla on erityisasema, kun hän lisäksi toimii Timon varamiehenä projektipäälllikön tehtävissä (katkoviiva kuvassa). Jukan varaprojektipäällikön tehtäviin kuuluu olla selvillä Timon hommista ja suorittaa tarvittavat operaatiot (esimerkiksi dokumenttipalautukset) silloin kun Timo on estynyt. Koko rakennettu projektiorganisaatio on myös tarkoitettu tiettyjen riskien minimoimiseen, joista lisää riskienhallintaosassa.  

Joillakin projektiryhmän jäsenillä on useita vastuualueita. Tähän tulokseen on tultu yhteisissä palavereissa, joissa on kyselty henkilöiden halukkuutta, taitoa ja aikaa vastata vastuualueistaan. Näissä tapauksissa vastuualueiden töiden aikataulutus on voitu tehdä järkevästi, eikä samalle henkilölle tule liikaa päällekkäisiä  toimia vastuualueensa johdosta. Ohjelmistosuunnittelu -vastuualueissa kaikilla on vastuu vain omasta koodistaan.

Tässä ja myöhemmissä dokumenteissa tullaan projektiryhmän jäseniin viittaamaan etunimellä, sillä päällekkäisyyksiä ei ole ja tapa on selkeämpi ja informatiivisempi kuin esimerkiksi nimikirjaimet "TR".

Nimi: Timo Ratilainen
Vastuualue(et): projektipäällikkö, web-master, asiakasvastaava
Email: tratilai@cc.hut.fi
Kotisivu: www.hut.fi/~tratilai
Muuta:
- työkemusta yli kaksi vuotta: kehittämistä, testausta ja dokumentointia isoissa ohjelmistoprojekteissa (>0,5 MLOC) ympäristöinä UNIX (HP, SUN) ja NT, kielinä C ja C++
- BASIC, C/C++, Java, Scheme, konekieli, HTML, PRO-C (SQL), OMT++, OOA/OOD, OpenGL, Microsoft Foundation Class (MFC), VC++, Rational Rose
- Tietotekniikan osastolta, pääaine Ohjelmistotuotannosta tietotekniikan osastolta ja sivuaine Kansainvälinen projektijohtaminen tuotantotalouden osastolta, 5. vuosikurssi 123ov

Nimi: Jukka Hynninen
Vastuualue(et): vara-projektipäällikkö, dokumentointivastaava, ohjelmistosuunnittelija
Email: jthynnin@cc.hut.fi
Kotisivu: www.hut.fi/~jthynnin
Muuta:
-työkokemusta mm. työasematuesta, verkkopankin ylläpidosta sekä tietoturvakonsultointia
-ohjelmointikielissä merkittävin osaaminen Perl, shelliskriptit, mutta myös Java, C, C++ ja assembler tuttuja, ylläpito (pienimuotoinen ohjelmointi, laitteistojen ja ohjelmistojen asennusta, virittelyä, ohjeistusta) erityisesti Solaris/Linux-ympäristöissä, NT, järjestelmien haavoittuvustestaus
-Tietotekniikan osastolta, pääaine Tietoliikenneohjelmistot (tietoturvan säie) tietotekniikan osastolta, sivuaine Yritysstrategia ja kansainvälinen liiketoiminta tuotantotalouden osastolta, 5. vuosikurssi 138ov

Nimi: Jonne Loikkanen
Vastuualue(et): käyttöliittymävastaava, ohjelmistosuunnittelija
Email: jloikkan@cc.hut.fi
Kotisivu: www.hut.fi/~jloikkan
Muuta:
- Ollut ohjelmistoalan töissa lähes 2 vuotta. Viimeisimmässä työprojektissa ollut toteuttamassa käyttöliittymää Weblogic Serveriin perustuvaan sovellukseen
- Java, C/C++... Erityisesti Java osaamista. Työskennellyt Oraclen tietokantojen parissa, vahvat SQL-taidot, html, xml
- Tietotekniikan osastolta, pääaine Ohjelmistojärjestelmät, sivuaine Tietoliikenneohjelmistot, 4. vuosikurssi, 100ov yli neljän keskiarvolla

Nimi: Anssi Keskinen
Vastuualue(et): ohjelmistosuunnittelija
Email: akeskine@cc.hut.fi
Kotisivu: www.hut.fi/~akeskine
Muuta:
- Työkokemusta reilut 1,5 vuotta: ohjelmointia Javalla NT ja UNIX ympäristöissä. HTML:ää satunnaisesti työssä ja yhdistystoiminnassa
- Java(RMI, EJB, JDBC) ja HTML, C/C++, PL/SQL, Perl, PHP, JavaScript, olioteknologia ja -mallinnus, UML, GNU-työkalut, VisualAge for Java, JBuilder, WebLogic (EJB server)
- Sähkö- ja tietoliikennetekniikan osastolta, pääaine Ohjelmistojärjestelmät, sivuaine Vuorovaikutteinen digitaalinen media, 140,5ov

Nimi: Jaakko Tuomimäki
Vastuualue(et): tietoliikennevastaava, ohjelmistosuunnittelija
Email: torakka@iki.fi
Kotisivu:
Muuta:
- Työkokemus: kaksi vuotta osa-aikaisena www-ylläpitäjänä ja mikrotukena, kaksi kesää tekemässä ylläpidollisia ja ohjelmien asennukseen liittyviä perl-skriptejä.
- Perl, C/C++, Java, javascript, TCP/IP, SQL, UML, HTML
- Tietotekniikan osastolta, pääaineena Tietoliikenneohjelmistot ja sivuaineena Ohjelmistojärjestelmät, 5. vuosikurssi 118,5ov

Nimi: Miiku Jaakkola
Vastuualue(et): laatuvastaava, testausvastaava, järjestelmävastaava, ohjelmistosuunnittelija
Email: mvjaakko@cc.hut.fi
Kotisivu:
Muuta:
- C/C++, Java, Scheme, Perl, Prolog, konekieli, SQL, HTML, UML, servletit, OpenGL, Clearcase
- Tietotekniikan osasto, pääaine Ohjelmistojärjestelmät, sivuaine Vuorovaikutteinen digitaalinen media, 4. vuosikurssi 135ov

Nimi: Tero Kilkanen
Vastuualue(et): arkkitehtuurivastaava, ohjelmistosuunnittelija
Email: tkilkane@cc.hut.fi
Kotisivu:
Muuta:
- Tietoliikennealan töissä 1,5 vuotta tutkinut QoS:ää ja WLAN:ia.
- C/C++, Java, assembler, Scheme, GNU ohjelmointityökalut, TCP/IP, SQL ja UML
- Tietotekniikan osastolta, pääaine Tietoliikenneohjelmistot, sivuaine Teletekniikka, 5. vuosikurssi, 130ov
 

3.2 Vastuualueet

Seuraavassa on kuvattu vastuualueiden tehtävät yleisluontoisesti.

Käytännössä töitä tehdään ryhmänä, mutta vastuualueen vastaava yrittää kontrolloida tehtäväkenttänsä tapahtumia, sillä projektipäälliköllä ei ole aikaa seurata kaikkia tapahtumia.

3.3 Sidosryhmät

Nimi: Asko Martio
Rooli: asiakas
Toimenkuva: TKK/ TAI-tutkimuslaitos
Email: asko.martio@hut.fi
Puhelin: 09-4514887

Nimi: Hannu Peltonen
Rooli: ohjaaja
Toimenkuva: TKK/ TAI-tutkimuslaitos
Email: hannu.peltonen@hut.fi
Puhelin: 09-4513244

Lisäksi sidosryhmäksi voidaan laskea kurssin vetäjät, joiden yhteystiedot ja roolit ovat kurssin kotisivulta[4].

EDMS-järjestelmän asiakkaat (kirjoitushetkellä ainoastaan KONE Oyj) voidaan ajatella sidosryhmäksi, mutta ainoastaan TAI-tutkimuslaitoksen puolesta, koska projektiryhmään ne heijastuvat ainoastaan TAI-tutkimuslaitoksen kautta. Meillä ei ole tarvetta (mahdollisuutta) vaikuttaa asiakkaamme asiakkaan päätöksiin. Lisäksi kyseisen sidosryhmän vaikutuksen määrä on kyseenalaista, sillä TAI-tutkimuslaitos tekee itsenäistä tutkimustoimintaa EDMS-järjestelmän pohjalta, eikä siihen vaikuta esimerkiksi taloudellisesti KONE Oyj:n toiminta. 

Projektilla ei ole muita merkittäviä sidosryhmiä joilla olisi vaikutusta ryhmän toimintaan.
 

4. Projektin tavoitteet ja päättäminen

4.1 Projektiryhmän tavoitteet

Projektiryhmän tavoitteet luonnollisesti poikkevat asiakkaan vastaavista, sillä projektiryhmän tavoitteet muodostuvat henkilöiden motivaatiotekijöistä kun taas asiakkaan vaatimukset järjestelmän ominaisuuksista. Projektiryhmä on määritellyt oman tavoitteensa yhteisissä palavereissa tiivistetysti seuraavasti:

"Projektiryhmämme tavoite on oppia mahdollisimman paljon projektimuotoisesta ohjelmistokehityksestä, toimittaja-asiakas -suhteesta sekä ryhmätyön merkityksestä projekteissa. Lisäksi pyrimme luonnollisesti omien etuuksiemme mukaan saamaan kurssista hyvän arvosanan, joka tukee ensimmäisen kohdan toteutumista."

Hyvän arvosanan saaminen -vaatimus on priorisoitu joustavaksi, eli siitä voidaan tinkiä jos esimerkiksi arvosanan 5 saaminen edellyttäisi kohtuutonta työmäärää.

4.2 Asiakkaan tavoitteet

Asiakas on määritellyt pyynnöstämme tavoitteensa tiivistetysti:

"Projektin tavoitteena on kehittää Java-ohjelma, jonka avulla voi helposti katsella ja muuttaa EDMS-tietokannan määrittelyitä. Ohjelman rakenteen pitää olla sellainen, että ohjelmaan voidaan myöhemmin lisätä uusia toimintoja EDMS:n tietomallin muuttuessa."

Ei-toiminnallisia vaatimksia on listattu seuraavassa. Ei-toiminnallisia vaatimuksia ei ole priorisoitu tarkemmin, sillä listassa olevat vaatimukset tulevat automaattisesti tehdyksi, kun projekti etenee ja projektille määriteltyjä laatuprosesseja noudatetaan.

- Ohjelma tehdään Javalla, JDK versio 1.2
- Ohjelman tulee toimia Windows-PC:ssä
- Ohjelmakoodin tulee olla selkeätä
- Ohjelman tulee olla laajennettavissa
- Ohjelman tulee olla helppokäyttöinen
- Ohjelman tulee olla hyvin dokumentoitu
- Englanniksi kirjoitetut HTML muotoiset tekninen määrittely ja käyttöopas -dokumentit 

Itse järjestelmän vaatimuksia on priorisoitu MUST, USEFUL ja NICE TO HAVE -tasoilla, jotka ovat luokkina selventävimpiä kuin esimerkiksi pelkät numerot.

Asiakas on priorisoinut ohjelman toiminnallisia vaatimuksiaan seuraavasti:

1. MUST: Oliotyyppien lisääminen ja poistaminen
2. MUST: Arvolistojen käsittely
3. MUST: Attribuuttien lisääminen ja poistaminen ja olemassa olevien attribuuttien ominaisuuksien muuttaminen
4. USEFUL: SSL-yhteydet tavanomaisten socket-yhteyksien lisäksi
5. USEFUL: Tilakaavioiden käsittely
6. USEFUL: Dokumenttien varausvälin käsittely
7. NICE TO HAVE: Varoitus kahdesta yhtäaikaisesta ylläpitäjästä
8. NICE TO HAVE: Käyttäjien lisääminen ja poistaminen
9. NICE TO HAVE: Monitor-toiminnallisuus
10. NICE TO HAVE: Protokollaviestien käsinkirjoitus
11. NICE TO HAVE: Undo-toiminto

Yllä oleva priorisointi on tehty vaatimuksille, jotka on ryhmitelty suunnilleen samoja toimintoja sisältäviksi ryhmiksi. Jokainen ryhmä sisältää pienempiä ja tarkempia vaatimuksia, mutta niiden kuvaus on jätetty vaatimusmäärittelyyn.

Asiakkaan vaatimusten "Top 10" ovat yllä olevissa listoissa ei-toiminnalliset vaatimukset ja MUST -luokan vaatimukset. Kuten helposti huomataan, on asiakkaalla verrattain vähän toiminnallisia vaatimuksia. Tämä johtuu siitä, että järjestelmän protokolla rajoittaa tehokkaasti tapoja joilla järjestelmän voimme tehdä ja toisaalta asiakkaalla ei ole tarvetta määritellä tarkkoja vaatimuksia käyttöliittymästä. Lyhesti voidaan sanoa, että olemme onnistuneet, jos saamme protokollan mukaiset toiminnot tehtyä; käyttöliittymästä voimme tehdä sellaisen kuin haluamme.

4.3 Projektin tavoitteet

Projektin tavoitteena on toteuttaa kaikki edellisen kappaleen listoissa mainitut toiminnallisuudet.

Jos projektissa joudutaan karsimaan vaatimuksista, niin se aloitetaan NICE TO HAVE toiminnoissa, joita voi joustavasti jättää pois lopputuotteesta. Vaatimusten pois jättäminen on tapauskohtaista ja riippuu voimakkaasti projektin silloisesta tilasta, resursseista, motivaatiosta ja asiakkaan silloisista vaatimuksista.

4.4 Projektin keskeyttämiskriteerit

Määrittelimme ehdottoman rajan projektin keskeyttämiselle: projekti keskeytetään jos keskimääräinen projektin jäsenen työmäärä ylittää 250 tuntia ennen luovutusvaihetta.

Kurssin puolesta tulisi työtä olla noin 200 tuntia (=5ov), joten on kohtuutonta vaatia yli 250 tunnin työmäärää. Keskeyttämisen sattuessa neuvottelemme asiakkaan (ja tietenkin kurssijohdon) kanssa jatkosta, esimerkiksi toimitamme olemassa olevan järjestelmän ja asiakas jatkaa kehitystä siitä. Toivottavasti tätä tilannetta ei tule ja se pyritäänkin välttämään monin seurantakeinoin jo hyvissä ajoin.

Projektin keskeyttämistilanteita on lisäksi lueteltu riskienhallintaosiossa.

4.5 Projektin päättämiskriteerit

Projektin päättäminen tapahtuu projektiryhmän ja asiakkaan yhteisessä tapaamisessa, joka sovitaan tarkemmin projektin edetessä. Tässä tapaamisessa tulee olla paikalla vähintään kaksi projektiryhmän edustajaa sekä asiakkaan edustaja. Tapaamisessa tulee päästä yksimielisyyteen projektin päättämisestä.

Projektille ei ole asetettu (paitsi kurssin toimesta) päättymispäivää, vaan siitä sovitaan erikseen, kuten yllä mainittu, lähempänä projektin pakollista loppumista, joksi lasketaan kurssin toimesta asetettu päättymispäivä.

5. Projektin resurssit

Seuraavassa on taulukoitu projektin mallin mukaisesti suunnitellut tuntimäärät per henkilö / toteutuneet tuntimäärät per henkilö.

Tarkempaan projektiresurssointiin on käytetty MS Project -ohjelmistoa, kuten kurssilla on vaadittu. Siinä on otettu huomioon mahdolliset lomat, tenttikaudet ja jäsenten muut estymiset. Lisäksi projektin aikataulutukseen on varattu huomattava määrä ns. suunnittelematonta työtä, koska projektin aikaresurssoinnissa suositellaan käytettävän jopa 10-50% marginaaleja. Tämä mahdollistaa tarvittaessa joustavat poikkeamat projektisuunnitelman aikataulutuksesta. Aikataulutus tehdään silti mahdollisimman tarkasti, eikä määrittelemättömään työn antamaan näennäiseen turvaan luoteta liikaa.

Ohjaaja on kertonut pystyvänsä konsultoimaan projektiryhmäämme koko projektin ajan, mutta kyseiselle työajalle ei ole erikseen tehty varauksia. Lisäksi asiakkaan työntekijä, Kim Gunell, yksi Jedi-työkalun kehittäjistä, on luvannut auttaa tarvittaessa.

Käytämme ohjelmistokehitykseen korkeakoulun tarjoamia laitteistoja. Osa projektiryhmän jäsenistä pystyy käyttämään myös kotitietokoneitaan apuna kehityksessä. Suurin rajoittava tekijä voi olla ohjelmistotyöluokan suuri käyttöaste, koska luokassa on rajallinen määrä koneita, joista osa on vielä varattu tietyille ryhmille. Lisäksi luokkaa käyttää sekä ohjelmatyö- että ohjelmistojen testaus -kurssin oppilaat. Luokan käyttöä täytyy suunnitella tarkemmin ryhmän kesken, jos ilmenee ongelmia.

Asiakas tarjoaa ns. integrointi-koneen käyttöömme Spektrin tiloissa. Kyseisen koneen käytössä ei ole suurempia rajoituksia, kunhan kulkuoikeudet on saatu kuntoon.

Teoreettinen projektin laskutus olisi 421000 markkaa. Tämä muodostuu 300 markan tuntiveloituksesta per projektijäsen, sekä kirjojen ym. materiaalin hankinnasta(1000 markkaa). Kurssin sääntöjen mukaan projektiryhmän jäsenet eivät saa nauttia etuuksia kuten palkkaa, bonuksia tai työsuhdeasuntoja asiakkaan puolelta.

6. Projektissa käytettävät menetelmät ja työkalut

6.1 Katselmointi

Projektin aikana toteutetaan katselmointikäytäntöä kaikille palautettaville dokumenteille sekä tuotetulle koodille. Katselmoinnilla pyritään takaamaan palautusten korkea laatu sekä koodin virheettomyys, selkeys ja yhdenmukaisuus. Tutkimusten mukaan katselmointi on tehokkaampaa kuin testaus virheiden löytämisen suhteen (katselmointi löytää 45-70% virheistä, kun testaus vain 15-50%), joten panostamme erityisesti katselmointiin[6].

Julkaistavan dokumentoinnin ja koodin lisäksi ryhmä epävirallisesti katselmoi tapaamisissaan tärkeitä suunnitelmia esim. arkkitehtuurista tai testaussuunnitelmista.

6.1.1 Dokumenttien katselmointi

Yllä oleva kuva esittää projektin dokumenttien palautusjärjestelmää. Ainoastaan Timolla (ja erikoistapauksissa Jukalla) on oikeus palauttaa vaadittuja dokumentteja kurssin vetäjille. Tämä tapahtuu siten, että vaikka koko projektiryhmä dokumentteja tuottaa, menevät ne aina katselmoinnin kautta palautukseen ja katselmoinnin voi ainoastaan hyväksyä Timo (erikoistapauksissa Jukka).

Palautusjärjestelmä on vielä varmistettu siten, että ainoastaan Timolla (ja varmuudeksi Jukalla) on käyttöoikeudet ryhmän kotisivulle[5] ja sitä kautta dokumenttien muuttamiseen.

Katselmoinnin säännöt dokumenteille ovat:

• katselmoinnin hyväksyjän lisäksi vähintää yksi katselmoija (mieluiten mahdollisimman moni ryhmän jäsenistä)

• katselmoitava dokumentti tulee olla paperiversiona jokaisella katselmoijalla ja niihin tulisi tutustua ennen katselmointi tilaisuutta

• katselmoinnissa luetaan rauhassa dokumentti pienissä osissa (joku selittänyt ensin osan tarkoituksen) ja joka vaiheen jälkeen sisällöstä keskustellaan

• virheet, puutteet yms. otetaan ylös ja ennen dokumentin hyväksyntää korjataan dokumenttiin

• hyväksynnästä tulee merkintä dokumenttiin ja versionumero hyppää seuraavalle kokoluvulle (esim. 3.4 -> 4.0)

6.1.2 Ohjelmakoodin katselmointi

Luovuimme vaiheen T2 aikana tehdyllä päätöksellä koodikatselmoinnista.

6.2 Työkalut

6.2.1 Kehitystyökalut ja apuohjelmat

Projektiryhmän kehitysympäristö on Niksulassa Teknillisessä Korkeakoulussa Tietotekniikan talolla Espoon Otaniemessä.

Laitteistopohjana UNIX-järjestelmä vaikkakin itse EAT-työkalu tehdään Windows NT -ympäristöön jossa sitä myös testataan

Seuraavaan on lueteltu projektiryhmän käyttämät ohjelmistot kehitykseen ja testaukseen (vastuuhenkilönä on järjestelmävastaava):

• Java Development Kit (JDK1.2)

• JRE Windows-PC

• koodieditointi vapaata kehittäjän mieltymysten mukaan: Emacs, notepad... koska versiohallinta keskitettyä

• CVS versionhallintaan

• debuggaus: JDB tulee JDK:n mukana

• Rational Rose 2000 Enterprise suunnitteluun

• MS Project 98 projektinhallintaan

• Netscape Composer ja Microsoft FrontPage dokumentointiin

Pyrimme tekemään ohjelmistokehityksestä mahdollisimman joustavan ohjelmistokehittäjän näkökulmasta, eli jokainen voi tehdä koodinsa missä haluaa, mutta versionhallintaan koodi täytyy tuoda Niksulan kautta (suljettu järjestelmä CVS:n alla). Joustavan ohjelmistokehityksen mahdollistaa järkevä arkkitehtuurisuunnittelu, tarpeeksi pienet ja itsenäiset moduulit, sekä tarkasti määritellyt rajapinnat moduulien välillä.

6.2.2 Tiedonkulku

Tiedonkulku tapahtuu suurimmaksi osaksi sähköpostilla. Ryhmällä on sisäinen sähköpostilista. Viestintä asiakkaan kanssa tapahtuu myös sähköpostitse. Kurssin vetäjien kanssa käytämme sähköpostia, korkeakoulun uutisryhmiä sekä erilaisia raportointijärjestelmiä, kuten myöhemmin kuvattu. 

Koska kurssijohdon tai asiakkaan taholta ei ole tullut vaatimuksia ylläpitää projektille kotisivuja, on ryhmä valjastanut EAT-projektin kotisivut omaan käyttöönsä[5]. Kotisivuja käytetään yleiseen tiedon jakamiseen, projektidokumenttien välitykseen ja hyödyllisten linkkien jakamiseen.

6.2.3 Raportointi

Projektiryhmä raportoi kurssin vetäjille kuten kurssidokumentaatiossa on määritelty. Tämä käsittää seuraavien järjestelmien käytön:

• Burana-järjestelmän virhe- ja kokoraportointiin

• Tirana-järjestelmän tuntiraportointiin

• Lisäksi projektipäällikkö tekee Vica-työkalulla tarvittaessa raporttitiedon visualisointeja

Asiakkaalle raportointi tapahtuu tapauskohtaisesti. Raportoinneista sovitaan erikseen tapaamisten yhteydessä tai sähköpostilla. Lisäksi asiakkaalla on mahdollisuus tutustua Burana- järjestelmän tietoihin.

6.2.4 Dokumentointi

Projektiryhmällä on käytössä dokumentointijärjestelmä (palautukselle ja kontrollille) kuten aikaisemmin kuvattiin. Lisäksi projektiryhmän ulkopuolelle menevät dokumentit pyritään saattamaan yhtenäiseen muotoon käyttämällä dokumenttipohjaa, jonka mukaan tämäkin dokumentti on tehty. Tämän varmistaa projektin projektipäällikkö yhdessä dokumenttivastaavan kanssa, joiden kautta kaikki dokumentit viime kädessä menevät. Kaikki julkaistavat dokumentit katselmoidaan. Kaikki julkaistava dokumentaatio on html-muodossa. Julkistettavien dokumenttien tekemiseen löytyy ohjeita kurssin kotisivulta.

Dokumentointivastaava tekee lisäksi asikastapaamisista muistiot jotka lähetetään sähköpostilistalla jokaiselle ryhmän jäsenille.

Dokumentin mallipohjasta saa parhaimman käsityksen tutkimalla tätä dokumenttia. Mallipohja on tehty Netscape Composer ja Microsoft FrontPage -työkaluilla ja se on projektijäsenten vapaassa käytössä dokumentointia varten. Mallipohjassa käytetään standardifontteja ja -määrityksiä, paitsi taustavärin suhteen, joka on harmaa luettavuuden parantamiseksi ja silmien rasituksen vähentämiseksi. Mallipohja on saatavissa projektiryhmän kotisivuilta. Mallipohjan mukaan tehdyillä dokumenteilla on yhtenäinen otsake, jossa on tietoa dokumentin nimestä, ryhmästä ja projektista. Dokumenteilla on lisäksi muutoshistoria, joka sisältää muutoksen tekijän, päivämäärän, version ja tehtyjen muutoksien kuvauksen. Lisäksi mallipohjassa on katselmointihistoria, eli aina kun dokumentti katselmoidaan merkitään katselmoijat, päivämäärä, hyväksyjä ja uusi versionumero. Katselmoinnin jälkeen versionumero nousee seuraavaan kokonaiseen lukuun (eli esim. 3.4 -> 4.0). Dokumenteilla ei ole vastuuhenkilöä, vaan muutoshistoriasta voidaan katsoa ketkä kaikki ovat vastuussa dokumentista ja mahdolliset kysymykset voi esittää suuremmalle joukolle henkilöitä.

Dokumentit nimetään kurssikäytännön mukaisesti:

• projektisuunnitelma = ps[x].html

• vaatimusmäärittely = vm[x].html

• edistymisraportti = er[x].html

• jne.

Jossa x tarkoittaa versionumeroa alkaen numero ykkösestä.

Asiakkaalle menevät dokumentit kirjoitetaan englanniksi ja html-formaatissa. Dokumentit siirretään ryhmän kotisivuille ennen määräaikoja jotta asiakas voi myös käydä tutustumassa dokumentaatioon ja kommentoida sitä halutessaan tai kurssin puolesta pakollisesti.

6.2.5 Hakemistorakenne

Hakemistojärjestelmä tehdään Niksulaan EAT -työkalun osien mukaan, jotka määritellään myöhemmin arkkitehtuurimallissa. Lisäksi ohjelmatyöluokan palvelimen tarjoamaa levytilaa käytetään hyväksi, jos se nähdään tarpeelliseksi.

Ryhmän jäsenillä on lisäksi omat hakemistonsa ryhmän hakemistossa omia tuotoksiaan varten.

6.2.6 Suunnittelumenetelmät

Arkkitehtuurin kuvauksessa käytetään UML-notaatiota (lähinnä Rational Rose:n muodossa), kun se käytännölliseksi katsotaan. Arkkitehtuurin määrityksessä yritämme lisäksi hyödyntää oliomallinnuksesta saatuja kokemuksia teollisuudessa, joista lisää arkkitehtuurivaiheessa.

6.2.7 Ohjelmakoodin ulkomuoto ja kommentointi

Koodin tyyliksi määrittelemme Sunin Java-koodin tyylioppaan[8] ja  kommentointiin JavaDoc -tyylioppaan[9]. Ohjelmistokommentit, muuttujat yms. kirjoitetaan englanniksi.

6.2.8 Laadunvarmistus

Laatu pyritään varmistamaan koodin osalta katselmuksilla sekä kattavalla testauksella. Lisäksi hyvä arkkitehtuurisuunnittelu mahdollistaa laadukkaan lopputuotteen, joten panostamme erityisesti helposti tulevaisuudessa muokattavaan arkkitehtuuriin. Dokumentoinnin laatu varmistetaan katselmointijärjestelmällä kuten aikaisemmin on kerrottu. Lisäksi koko projektin laatua pyritään määrittämään erilaisilla mittareilla ja seurannalla. Laatujärjestelmästä on kerrottu lisää laatusuunnitelmassa[10].

6.2.9 Varmuuskopiointi

Projektipäällikkö ottaa parhaaksi katsomansa ajoin varmuuskopiot haluamistaan osista. Tiedot tallennetaan projektipäällikön ja varaprojektipäällikön omaan korkeakoulun tarjoamaan kotihakemistoon. Lisäksi projektiryhmän jäseniä kannustetaan pitämään mahdollisimman paljon omia varmuuskopioita tallessa. Tarvittaessa voidaan korkeakoulun ATK-keskukselta pyytää lisätilaa PDM-ryhmää varten varmuuskopioita varten.

Varmuuskopiointi tehdään myöhemmin automaattiseksi, jokapäiväiseksi toiminnoksi Niksulan CVS:ssä.

6.2.10 Palaverikäytännöt

Asiakastapaamiset järjestetään erikseen sovittuna aikoina. Tällä pyritään välttämään turha tapailu, joka rasittaa kaikkia osapuolia. Yleiseksi tapaamisajaksi on sovittu perjantai aamulla kello yhdeksän asiakkaan luona Spektrissä.

Ryhmäpalaverit sovitaan myöskin erikseen. Niiden asialista lähetetään erikseen sähköpostilistan välityksellä. Tapaamisilla on aina vastaava, yleensä projektipäällikkö, joka ohjaa keskustelua, päättää tapaamisen lopettamisesta ja huolehtii, että tapaamisessa oli jokin lopputulos, esimerkiksi päätös jostakin asiasta.

7. Projektin ositus, vaiheistus ja resurssointi

Projekti on ositettu yleisellä tasolla kuten kurssin kotisivuilla on mainittu. Tarkempaan vaiheistukseen ja resurssointiin käytetään MS Project -työkalua. Lisäksi tietyn projektin vaiheen tarkempaa ositusta on käsitelty alla olevien vaihe-kappaleiden sisällä.

Seuraavassa on projektin vaiheiden (kuva yllä) kuvaukset:.

• PS: Projektin suunnitteluvaiheen aikana aihe valitaan, projekti perustetaan ja se organisoi toimintansa. Lisäksi asiakkaan ongelma analysoidaan ja projektin resurssit kohdistetaan mahdollisuuksien mukaan.
• T1-T4: Toteutus tehdään iteratiivisesti ja inkrementaalisesti niin, että kokonaisuus aluksi hahmotellaan korkeammalla abstraktiotasolla ja sen jälkeen tehdään tarkennuksia projektin edetessä.
• LU: Luovutusvaiheessa korjataan tai dokumentoidaan jäljellä olevat avoimet virheet, viimeistellään järjestelmään liittyvä dokumentaatio ja kirjoitetaan projektin loppuraportti.

Jokaiseen vaiheeseen kuuluu huomattava määrä palautettavaa dokumentaatiota, josta tarkemmin kurssin kotisivuilla.

Seuraavassa on projektin vaiheiden aikataulut:

• Projektin suunnittelu 26.9.2000 - 18.10.2000 (3 viikkoa)
• Toteutus 1 19.10.2000 - 10.11.2000 (3 viikkoa)
• Toteutus 2 11.11.2000 - 15.12.2000 (5 viikkoa)
• Toteutus 3 16.12.2000 - 16.2.2001 (9 viikkoa - joululoma)
• Toteutus 4 17.2.2001 - 23.3.2001 (5 viikkoa)
• Luovutus 24.3.2001 - 27.4.2001 (5 viikkoa)

Jokaisen vaiheen lopussa on projektikatselmus, jossa projektiryhmä esittelee projektin tilan.

Projektin vaiheisiin on varattu 20 prosentin määrittelemätön työ osa. Tämä osa katsottiin tarpeelliseksi, koska alan kirjallisuus suosittelee jopa 20-50 prosentin kokoista marginaalia[7]. Määrittelemätön työ on ensisijaisesti varattu työlle jota ei ole osattu/muistettu laittaa projektin ajankäyttösuunnitelmaan (MS Project tiedosto), mutta se on myös projektipäällikön keino varmistaa ettei projekti ylitä sille varattua aikaa.

Seuraavissa alaotsikoissa on kerrottu tarkemmin jokaisesta vaiheesta. Toteutuneet tuntimäärät täydennetään luonnollisesti seuraavan vaiheen alkaessa, kun toteutuneet tunnit ovat tarkasti selvillä. Vaiheet on sisäisesti vielä ositettu, jotta projektia voisi paremmin kontrolloida ja tarvittaessa nopeasti muuttamaan panostusta työtehtäviin. Vaiheiden sisällä osien nimet alkavat vaiheen lyhenteellä ja sitten roomalainen numero osoittaa osan numeron vaiheen sisällä (esim. T3-III tarkoittaa T3-vaiheen osaa numero 3).

Toteutuneet tuntimäärät on otettu ViCa -järjestelmän tietokannasta vaiheen loputtua.

7.1 Projektin suunnittelu

Seuraavassa on tarkemmin vaiheen arvioitu tuntityömäärä projektihenkilöittäin / toteutunut tuntityömäärä projektihenkilöittäin (ei sisällä ennen PS-vaihetta tehtyjä tunteja).

Projektin suunnittelu -vaihe sisälsi projektiorganisaation, kehitysympäristön, vaatimusten ja vaadittujen dokumentaatioiden suunnittelua. Koodia vaiheessa ei tuotettu, vaikka tutustuminen asiakkaan jo olemassa olevaan koodiin aloitettiin.

PS-vaihetta ei ole ositettu, koska vaihe on epämääräinen projektin aloituksen ja kurssin opetuksen seuraamiseen painottuva.

7.2 Toteutus 1

Seuraavassa on tarkemmin vaiheen arvioitu tuntityömäärä projektihenkilöittäin / toteutunut tuntityömäärä projektihenkilöittäin.

T1-vaihe oli vielä suurimmaksi osaksi suunnittelua, mutta myös pieni prototyyppi saatiin valmiiksi.

Vaihe on sisäisesti jaettu kahteen osaan:

1. T1-I-osa 19.10 - 31.10
2. T1-II-osa 1.11 - 10.11

Vaiheen tärkeimmät kohdat:

• Toiminnallisen määrittelyn tekeminen, erityisesti arkkitehtuurimallinnus (osat T1-I ja T1-II)
• Arkkitehtuurin päättämisen jälkeen ensimmäinen prototyyppi (osa T1-II)
• Prototyyppi jää käyttöön Pinjan muutoksien osalta (käyttöliittymäosa heitetään pois) ja sitä ruvetaan laajentamaan seuraavissa vaiheissa

Saimme tehtyä toiminnallisen määrittelyn ja testaussuunnitelman kuten suunnittelimme. Arkkitehtuuriksi varmistui kaksi-vaihe arkkitehtuuri, jossa on käyttöliittymäosa ja Pinja-osa. Välilogiikka (ns. bisneslogiikka) sijoitetaan tarvittaessa kumpaankin osaan. Teknisestä määrittelystä saimme ensimmäisen version valmiiksi, mutta sitä ei vielä T1-vaiheessa palauteta. Lisäksi T1-II -vaihe tuotti prototyypin, jonka laajentamista jatkamme seuraavassa vaiheessa. Protyypissä on Pinjaan tehty muutoksia sekä rakennettu Swing-komponenteista Pinja-muutoksien testaamista varten käyttöliittymä.

7.3 Toteutus 2

Seuraavassa on tarkemmin vaiheen arvioitu tuntityömäärä projektihenkilöittäin / toteutunut tuntityömäärä projektihenkilöittäin.

T2-vaihe tulee sisältämään T1-vaiheessa aloitetun prototyypin laajennusta vaatimuksien mukaan. Lisäksi teknistä määrittelyä täydennetään rinnakkain järjestelmän kehityksen kanssa. T1-vaiheessa tuotettu prototyyppi jää käyttöön Pinjan muutoksien osalta ja käyttöliittymäosa heitetään pois.

Vaihe on sisäisesti jaettu kahteen osaan:

1. T2-I-osa 11.11 - 26.11
2. T2-II-osa 27.11 - 15.12

Vaiheen tärkeimmät kohdat:

• Teknisen määrittelyn tarkentaminen (lähinnä osa T2-I)
• Käyttöliittymäosan ohjelmoinnin aloittaminen
• Pinja-osan prototyypin laajentaminen vaatimusten [oliotyypit] ja [arvolistat], joista tarkemmin vaatimusmäärittelyssä[11]
• Testausta prototyypille (osa T2-II)

Vaiheesta T2-I poistumisen ehto on teknisen suunnitelman valmistuminen.

Vaiheen T2-II poistumisen ehto on Pinjan-osan [oliotyypit] ja [arvolistat] -vaatimusten toteuttaminen asteelle, jossa niitä voidaan demota T2-vaiheen lopussa.

7.4 Toteutus 3

Seuraavassa on tarkemmin vaiheen arvioitu tuntityömäärä projektihenkilöittäin / toteutunut tuntityömäärä projektihenkilöittäin.

T3-vaihe tulee sisältämään kaikkien loppujen vaatimusten toteuttamisen. Lisäksi teknistä määrittelyä täydennetään rinnakkain järjestelmän kehityksen kanssa. T4 toteutusvaihetta on tarkoitus painottaa testauksen ja korjausten suuntaan, joten tämä vaihe sisältää paljon toiminnallisuuden lisäämistä EAT:iin.

Projektiryhmä on periaatteessa hajaantunut kahteen sisäiseen ryhmään. Jonnen vastuulla oleva hoitaa käyttöliittymän (GUI) tulevia muutoksia ja lisäyksiä ja Teron vastuulla on taas Pinja Interfaceen tulevat muutokset. Jonnen ryhmään kuuluvat Jukka ja Miiku ja Teron ryhmään Anssi ja Jaakko.

Vaihe on sisäisesti jaettu kolmeen osaan:

1. T3-I-osa 18.12 - 31.12
2. T3-II-osa 1.1 - 21.1
3. T3-III-osa 22.1 - 16.2

Vaiheen tärkeimmät kohdat:

• Vaatimusten [attribuutit],  [tilakaaviot], [varausväli], [logincheck], [käyttäjänhallinta], [monitor], [protokollacli], [undo] ja [ssl] siltä osin kuin se ei ole jo valmis. Kuvaukset tarkemmin vaatimusmäärittelyssä[11].
• Teknisen määrittelyn täydentäminen
• Moduulitestausta, käyttöliittymätestausta ja integraatiotestausta
• Testausympäristön luonti
• Virhekäsittelyn suunnittelu ja toteutus EAT-työkaluun

Vaiheesta T3-I ei ole poistumisen ehtoa, koska kyseessä on lomavaihe.

Vaiheen T3-II poistumisen ehto on [attribuutit], [ssl] ja [protokollacli] vaatimuksien valmistuminen testattavalle asteelle.

Vaiheen T3-III poistumisen ehto on [tilakaaviot], [varausväli], [logincheck], [käyttäjänhallinta], [monitor] ja [undo] vaatimuksien valmistuminen testattavalle asteelle.

Koska kaikki mainitut vaatimukset sisältävät muutoksia sekä Pinja Interfaceen että GUI-osaan, joutuu kumpikin projektiryhmän sisäinen ryhmä tekemään kaikkia mainittuja vaatimuksia. Tietyn toiminnallisuuden vaatiman työn jakaminen on yleensä juuri sopivan kokoinen työtehtävä annettavaksi jommalle kummalle projektiryhmän sisäiselle ryhmälle.Tapa on muutenkin hyvä, sillä ryhmän vetäjät tuntevat osa-alueensa parhaiten. Näin vältytään turhalta byrokratialta ja suunnitelulta, joka näin pienessä projektissa yleensä on vain haitaksi. Kyseinen menetelmä vaatii kuitenkin toimiakseen sen, että esimerkiksi projektipäällikkö seuraa hyvin tiiviisti osatehtävien toteutumista.

Bugien korjaukseen varataan aikaa vasta vaiheessa 4, koska se on varsinainen testausvaihe. Jos projektin jäsen kuitenkin käyttää aikaa bugien korjaukseen jo tässä vaiheessa, tulee se merkitä määrittelemättömäksi työksi ja selventää käytettyä aikaa kommentein.

7.5 Toteutus 4

Seuraavassa on tarkemmin vaiheen arvioitu tuntityömäärä projektihenkilöittäin / toteutunut tuntityömäärä projektihenkilöittäin.

T4-vaihe tulee sisältämään kaikkien loppujen vaatimusten toteuttamisen, tosin [undo] vaatimuksen toteuttamisesta keskustelemme asiakkaan kanssa. Lisäksi teknistä määrittelyä täydennetään rinnakkain järjestelmän kehityksen kanssa. Erityisesti on huomattava, että koska edellisessä vaiheessa ei saatu toteutettua haluttuja vaatimuksia, joudutaan niitä jatkamaan tässä vaiheessa. Tämän ei pitäisi aiheuttaa ongelmia, koska siihen on varauduttu esimerkiksi määrittelemättömän työn lisällä.

Vaihe on sisäisesti jaettu kolmeen osaan:

1. T4-I-osa 17.2 - 2.3
2. T4-II-osa 3.3 - 20.3

Vaiheen tärkeimmät kohdat:

• Vaatimuksista saatetaan loppuun [attribuutit] ja [logincheck].
• Vaatimukset [käyttäjänhallinta] ja [monitor] aloitetaan ja saatetaan loppuun.
• Asiakkaan kanssa keskustellaan [undo] vaatimuksen tarpeellisuudesta. Vaatimusten kuvaukset tarkemmin vaatimusmäärittelyssä[11].
• Teknisen määrittelyn täydentäminen
• Moduulitestausta, käyttöliittymätestausta ja integraatiotestausta
• Virhekäsittelyn loppuunsaattaminen

Vaiheen T4-I poistumisen ehto on [attribuutit], [logincheck] vaatimuksien valmistuminen.

Vaiheen T4-II poistumisen ehto on [käyttäjänhallinta] ja [monitor] vaatimuksien valmistuminen testattavalle asteelle.

7.6 Luovutus

Seuraavassa on tarkemmin vaiheen arvioitu tuntityömäärä projektihenkilöittäin / toteutunut tuntityömäärä projektihenkilöittäin.

Toteutuneet tunnit on otettu 19.4.2001, joten kaikki projektin toteutuneet tunnit eivät ole taulukossa, mutta ero lopullisiin tuloksiin on hyvin pieni ja merkityksetön koko projektin mittakaavassa.

Lu-vaihe tulee sisältämään testausta ja löytyneiden virheiden korjausta. Vaiheen lopussa EAT-ohjelmisto luovutetaan asiakkaalle. Ohjelmiston luovuttaminen ajoissa on myös vaiheen exit-kriteeri. Luovutuksen tulee tapahtua viimeistään perjantaina 20.4.2001.

Vaihetta ei ole sisäisesti jaettu osiin. Vaiheessa tullaan suorittamaan järjestelmä- ja käytettävyystestausta useina kierroksina (regressiotestausta), joiden välissä havaitut virheet pyritään korjaamaan.

8. Mittarit, seuranta ja ohjaus

Käytämme kurssin tarjoamia tapoja mitata ja seurata projektin edistymistä. Näistä tiedoista voi projektipäällikkö tehdä havaintoja projektin edistymisestä ja toimia sen mukaan. 

Projektipäällikkö pitää lisäksi kirjaa projektijäsenten tapaamisiin osallistumisesta. Tämä antaa yleistä käsitystä kyseisen henkilön halusta panostaa projektiin. Tosin se myös kertoo, jos projektihenkilö ei pysty muiden kiireiden (esimerkiksi työ) takia osallistumaan projektiin kuten tarvitsisi.

Projektin tilaa seurataan ryhmätapaamisissa sovituin ajoin (ei turhia kokouksia, jotka lannistavat osallistumisaktiivisuutta). Näissä tapaamisissa on varattu loppuun aikaa yleiselle juttelulle projektin asioista. Käytäntö on osoittanut, että tämä on yksi parhaimpia tapoja pitää koko projektiryhmä tietoisena projektin tilasta, kunhan vain tapaamisaktiivisuus saadaan pidettyä korkeana. Tosin tähän 'mittariin' liittyy henkilöstä riippuva liioittelu/vähättely vakio, joten projektipäällikön ei kannata luottaa pelkästään projektijäsenten sanomisiin vaan konkreettisesti mitata ja tutkia projektin oikeaa tilaa.

Asiakkaan puolelta seuranta ja ohjaus perustuu pitkälti asiakastapaamisiin sekä asiakkaille toimittamiimme dokumentteihin. Lisäksi projektin aikana voidaan sopia asiakkaan kanssa demotilaisuuksista, joissa demotaan EAT -työkalun sen hetkistä tilaa.

Projektipäällikkö laatii vaiheiden lopuksi edistymisraportin, jossa annetaan kattavampi yhteenveto projektin tilasta projektiryhmän ulkopuolelle. Projektipäällikkö lisäksi tutkii koko projektin ajan mahdollisten lisämittareiden käyttöä.

Lisäksi laatuvastaava pitää yllä omia mittareitaan projektin tilan ja laadun seurantaan.

9. Riskienhallintasuunnitelma

Seuraavassa on lueteltu projektin mahdolliset riskit.

Riskeissä on määritelty itse riski, sen havainnointi, syy, seuraus, ehkäisy ja reagointi. Varsinkin havainnointi on tärkeä kohta, sillä projektin alussa pyritään luonnollisesti varautumaan ja ehkäisemään riskejä, mutta ne joita ei voitu ehkäistä, pitää pystyä havainnoimaan jotenkin projektin kuluessa, jotta niihin voidaan reagoida.

Riskit ovat arvioimassamme todennäköisyys- ja vakavuusjärjestyksessä, sillä oikeiden todennäköisyyksien arvioiminen on yleensä mahdotonta ja melko hyödytöntä, varsinkin jos kaikkia mahdollisia riskejä on projektin alussa yritetty ehkäistä.

10. Muuta

10.1 Projektiryhmän sisäinen koulutussuunnitelma

Projektiryhmä pitää tarvittaessa sisäisiä koulutustilaisuuksia, jos siihen ilmenee tarvetta. Esimerkiksi CVS:n käyttöä voidaan opettaa niille jotka sitä eivät ole ennen käyttäneet.

Suuria koulutustarpeita ei ole, koska ryhmään pääsi vain jos Java-ohjelmointikieli on tuttu. Muita suuria osaamisvaatimuksia projektissa ei ole.

10.2 Asiakkaalle tarjottava koulutussuunnitelma

10.3 Asennusuunnitelma

Projektin lopputuote on itsenäinen Java-ohjelma, jonka asennus on helppoa. Ohjelma kopioidaan työasemaan, jossa sitä halutaan käyttää ja ohjelma käynnistetään. 

Ohjelman käyttäminen vaatiii JRE-ympäristön työasemalla.

Lähdeluettelo

[2] PDMG ryhmän sivut, http://www.cs.hut.fi/~pdmg/

[3] Dokumenttihallintajärjestelmän kuvausta, http://www.cs.hut.fi/u/pdmg/edms/Info.html

[4] Tik-76.115 Tietojenkäsittelyopin ohjelmatyö -kurssin kotisivut, http://www.cs.hut.fi/Opinnot/Tik-76.115/

[5] EAT-projektin kotisivut, www.hut.fi/~tratilai/pdm

[6] C.Jones: Softaware Defect-Removal Efficiency. (IEEE) Computer 29, 4, 1996, p. 94-95

[7] I. Haikala, J. Märijärvi, Ohjelmistotuotanto, Suomen ATK-kustannus, 1998

[8] Sunin määrittelemä Java-koodin tyyliopas, http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

[9] JavaDoc -tyyliopas, http://java.sun.com/products/jdk/javadoc/writingdoccomments/index.html

[10] EAT-projektin laatusuunnitelma

[11] EAT-projektin vaatimusmäärittely